home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 921 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. Date: Thu, 21 Jul 1994 01:46:38 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Dialogs!
  4. To: gem-list@world.std.com
  5. In-Reply-To: <199407021130.HAA01334@csa.bu.edu>
  6. Message-Id: <Pine.3.87.9407210138.A781-0100000@grad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. Hey, people!
  13.  
  14. We're saying to stop using dialogs.
  15.  
  16. Ok... you just threw away part of the OS and told peope to replace it 
  17. with their own code (or a library).
  18.  
  19. Hey, this is the way GEM is.  If we're going to require dialogs to be in 
  20. windows, then it should made part of the operating system.  
  21.  
  22. If we want all dialogs to be in windows, then we have to go knocking on 
  23. the doors of the OS developers and demand that they change the basic 
  24. functionality of the OS.  MultiTOS and Geneva should put dialogs for apps 
  25. automatically into windows and handle them accordingly.
  26.  
  27. But then you screw over everyone using an older machine without Geneva or 
  28. MultiTOS, and you screw up every older program running under the new OS 
  29. that expects the dialog box to stay in the same spot.
  30.  
  31. You're not asking for extentions to the OS, consistency, and added 
  32. functionality.  You're asking for REVOLUTION!  And as you know revolution 
  33. does not come without a BIG price.
  34.  
  35. I'm as supportive of dialogs-in-windows as the next guy, but we have to 
  36. face reality.  Good option, yes.  Requirement?  Definately NOT!
  37.  
  38. Every new program that supports that section of the GEM-List standards 
  39. should put dialogs in windows.  Fine.  Every program that wants to 
  40. properly support multuitasking, definately.
  41.  
  42. But then you still have the problem of every program containing extra 
  43. code for handling dialogs in windows, and each program having a different 
  44. handler from a different library developer.  There will be a lack of 
  45. consistency and a lot of wasted space.
  46.  
  47. Until this is part of the OS, you can't make it a requirement.  A little 
  48. 5k DA that's intended to make some setting and then quit certainly 
  49. shouldn't be required to puts its dialog in a window.  You won't have the 
  50. dialog open long enough!
  51.  
  52. And then to make standards on something as open-ended and unexplored as 
  53. amodal dialogs is not reasonable.  Some on the standards committee may 
  54. set requirements that library developers are unwilling or unable to 
  55. follow.  One standard from the GEM-List will not work well when different 
  56. apps have different requirements.  A smaller, simpler, less powerful 
  57. library may be just what the doctor ordered for some developer, but this 
  58. library may not live up to the requirements of the GEM list.
  59.  
  60. I think we need to explore this concept of the amodal dialog on the Atari 
  61. (it will be unique among computers, not like Apple or Windows... it's its 
  62. own animal and needs to be treated as a newly discovered species) for a 
  63. while before we make requirements about it.  Let's let a few developers 
  64. take a crack at it, using their own ideas and see what people really use 
  65. and want.  Let's let some healthy, unrestricted (by rules) competition 
  66. happen, so that the winner will TRULY be the best, rather than the one 
  67. that the 'government' picked, foolishly, haphazzardly, and one that met 
  68. their minimal requirements and lowest price bid.
  69.  
  70.  
  71. Hey, whatever happened to our discussion of color-palette handling?  I 
  72. especially likes my ideas.  :)  Could someone go back to those old 
  73. messages and digest what was discussed?
  74.  
  75.  
  76. Can someone tell me how to set up menu_popup's?  I'm baffled.  Do I 
  77. create a form with just string in it and put that in the MENU structure?  
  78. I'm kinda lost.  Could someone explain the process that one goes 
  79. through?  What do you do in the resource editor, what you do in your 
  80. code, etc?  Thanks!
  81.  
  82.  
  83.  
  84.